fix(execution): 레드팀 치명 2건 수정 + v1.9.0 (STO-1729, STO-1730) - #55

/redteam이 서로 직교하는 두 축(L3 운영 현실, L4 호출자 정체성)에서 치명 2건을
냈다. 둘 다 코드 리뷰 두 층(openswarm review, pr review)을 통과한 뒤에 나왔다 —
그 리뷰들이 틀린 게 아니라, "프로세스가 살아 있고 사람이 보고 있다"는 전제
위에서만 맞는 말이었기 때문이다.

STO-1729 — 주문은 절대 재전송하지 않는다
  client.make_request의 기본 retries=2가 주문 POST에도 적용됐다. 타임아웃은
  응답에 걸린 것이지 동작에 걸린 것이 아니다. 접수된 주문의 응답만 유실됐는데
  같은 본문을 다시 보내면 중복 주문이 되고, KIS는 멱등키를 받지 않아 거래소가
  걸러줄 수도 없다. 이제 GET이 아닌 요청은 전송 1회로 고정된다.

  `retries > 1`이 아니라 `!= 1`로 판정한다. 전자는 retries=0을 통과시켜
  range(0) 루프가 아예 돌지 않고, 주문이 나가지 않은 채 "Unknown error"로
  끝난다 — 호출자는 그걸 전송 실패와 구분할 수 없다. (커밋 전 리뷰 지적)

  패키지의 POST 16곳은 전부 */order_api.py이고 토큰 발급은 requests.post를
  직접 쓴다. 이 전제가 깨지면 먼저 알도록 테스트로 고정했다.

STO-1730 — 집행 원장
  TWAP/VWAP은 30~120분 블로킹이다. 그 사이 프로세스가 죽으면(SIGKILL·절전·
  OOM·에이전트 타임아웃) 나간 주문번호가 메모리와 함께 사라졌다. 실측으로
  SIGTERM 8초에 stdout 0바이트, stderr에는 이미 실행된 슬라이스 흔적만 남았다.

  이제 자식 주문은 거래소 접수 직후 JSONL 원장에 flush + fsync된다. SIGKILL
  서브프로세스 테스트로 "핸들러 없는 즉사에도 주문번호가 디스크에 남는다"를
  직접 증명한다.

  미완료 원장(=죽은 실행)이 같은 종목에 있으면 새 집행을 거부한다. 가드는
  CLI가 아니라 runner에 둔다 — CLI만 막고 문서화된 Python API를 열어두면
  같은 치명이 그대로 남는다. (커밋 전 리뷰 지적)

  가드가 걸리는 것은 처리되지 않은 즉사뿐이다. 정상 완료와 Ctrl+C는 원장을
  닫으므로 통과하고, 당일 범위라 한 번의 크래시가 종목을 영구히 막지 않는다.
  실측으로 세 경로 모두 확인했다.

원장 기록 실패는 주문을 중단시키지 않는다. 디스크가 찼다고 절반 집행된 부모
주문을 버리는 것이 더 나쁘다. 그래서 주문번호를 stderr 진행 출력에도 싣는다.

검증
- 신규/수정 모듈 100% 커버리지, 단위 테스트 241개
- 전체 스위트 회귀 0건 (51 failed/16 errors는 로컬 py3.14 환경의 기존 문제로
  변경 전과 동일). passed 2133 → 2190
- 테스트가 ~/.kis-agent에 실제 원장 65개를 흘리던 것을 발견해 격리 픽스처 추가

릴리즈
- 1.8.0 → 1.9.0, CHANGELOG의 Unreleased 마감
- python -m build + twine check 통과 (wheel/sdist)

openswarm pr review가 Decision: REVISE를 냈다. 트레이스 본문은 "approval"이라
썼지만 구조화된 판정 줄이 정본이다.

가드가 종목 단위라 크래시한 매수가 청산 매도까지 막았다. 사고 직후 운영자가
가장 하고 싶은 일이 청산인데 도구가 그걸 방해하면, 가드가 있는 것이 없는 것보다
나쁘다. 중복 위험은 어차피 같은 방향에서 생긴다. 이제 같은 방향만 막는다.

문서가 "정상 종료와 Ctrl+C는 원장을 닫는다"고 주장하면서 테스트가 없었다.
수동으로 확인했을 뿐 고정하지 않은 것은 주장이지 보장이 아니다. cancelled·
aborted·partial 세 경로와 스킵 슬라이스 감사 기록까지 테스트로 고정했다.

가드가 보여주는 주문번호가 적게 나올 수 있다는 점도 명시했다 — 재전송을 하지
않으므로 응답이 유실된 주문은 접수됐더라도 failed로 기록된다. 대사의 출발점이지
완전한 목록이 아니고, kis order list가 정본이다.

리뷰가 지적한 검사-기록 사이 경합 창은 STO-1733으로 분리했다. 창이 밀리초이고
가드의 표적인 순차 재실행은 완전히 막히며, O_CREAT|O_EXCL 락이 필요한 별개
작업이다.

리뷰의 "retries 기본값이 정말 5에서 2로 줄었나" 확인 요청은 확인 결과 조치
불필요다 — 코드는 이미 2였고 docstring만 5라고 잘못 적혀 있었다. 이번에 맞췄다.

검증: 신규/수정 모듈 100% 커버리지, 회귀 0건 (passed 2190 → 2201)